home *** CD-ROM | disk | FTP | other *** search
- Subject: Re: Gem List (fwd)
- Date: Thu, 21 Jul 1994 10:51:39 -0400 (EDT)
- From: Chris Herborth <herborth@53iss6.waterloo.ncr.com>
- In-Reply-To: <2e2cfd5016cbf5@elfhaven.ersys.edmonton.ab.ca> from "Michel Forget" at Jul 19, 94 09:57:36 pm
- Message-Id: <9407211058.aq23347@ncrhub1.NCR.COM>
- Precedence: bulk
-
- What you wrote:
- > I'm not actually sure; I can only speak for myself, but I tend to respond
- > when people say something I disagree with. That is why I keep posting
- > these messages, though.
-
- Me too! :-\
-
- > >I'm
- > >presuming that you're playing devil's advocacte a little here, since nobody
- > >in their right mind would use the Malloc() GEMDOS call.
- >
- > Sigh. _I_ use it. (Yes, I feel stupid now, since now at least one reason
- > why I should not.) Using malloc() is only a delay, though, for TOS 1.0
- > users. If you allocate a lot of memory (like MasterBrowse does) then
- > malloc() will end up calling Malloc() more that sixteen times, and you
- > can say bye-bye to TOS 1.0. Is there -another- reason why I should not
- > use it?
-
- Most C libraries that have decent malloc() support (ie, to work around
- that STUPID Malloc() bug) let you set the size of the smallest "chunk"
- that actually gets allocated with Malloc(); I think GNU C's defaults to
- 64k, but you can change it by setting _blksize or something like that
- (an extern long variable). You could set this based on the size of the
- file (ie, set _blksize to 1/2 the file size or 1x the file size) and
- then malloc() to your heart's content... only 1 (or maybe 2) call to
- Malloc() will be generated, saving the poor TOS 1.0 user from mysterious
- crashes...
-
- --
- ----------========================_ /\ ============================----------
- Chris Herborth \`o.0' herborth@53iss6.Waterloo.NCR.COM
- Information Products Developer =(___)=
- AT&T Global Information Solutions U
-